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(57) Abstract 



A data warehouse system and method. The data warehouse includes a memory and a processor. The memory includes a database 
having a plurality of data entries. The processor includes a cache and an override engine, wherein the cache includes a subset of the 
plurality of data entries and wherein the override engine extracts data from the cache for viewing by a user, modifies the data in response 
to one or more user commands and saves the user commands to a file for later application to the database. 
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WO 99/57658 PCT/US99/09633 
SYSTEM AND METHOD FOR UPDATING A MULTI-DIMENSIONAL DATABASE 

Rarkg™" nd nf the Invention 

Field of the Invention 

The present invention relates generally to database management, and more 
5 particularly to a system and method for manipulating facts in multi-dimensional databases. 

Background Information 

Business decision-makers operating in today's rapidly changing business environment 
need answers to a host of questions that directly impact their ability to compete in the 
marketplace. To manage and use information competitively, many companies are 
10 establishing decision support systems built around a data warehouse. A data warehouse 
stores a company's operational and historical data in an integrated relational database for 
decision support applications, business data access and reporting. Decision support systems 
access such databases to analyze and summarize corporate performance. 

Data warehouses employ relational database management systems that use a language 
15 such as SQL to retrieve rows and columns of numeric data. The systems may also permit 
access to textual files such as documents. Data may be accessed directly via user-generated 
SQL commands, or indirectly, via an interface which generates the desired SQL commands. 
Applications such as Business Objects from Business Objects S.A., France, 
(http://www.businessobjects.com)i Forest and Trees-from Platinum Technology Inc., . 
20 Oakbrook Terrace, EL, (http://www.platinumiCom)^and Pilot's Lightship from Pilot Software 
J Inc., Cambridge, MA, (http://www.pilotSw.com) are: typical of off-ther shelf applipatjons 
which use browse windows under the control of end-users to generate the SQL code needed 
to analyze the data in the data watehp^se. , ; 

TWs approach, however, runs into significant performance problems associated with 
25 PC and network limitations. Queries generated by inexperienced users can dominate an<J ', 
Crash ttife database, or cause excessive network congestion. In addition, there is no 
mechanism for shifting large processes so they execute during! off-peak hours. 

OLAP (OnLine Analytic Processing) technology, alsoHcailed multidimensional 
analysis can also be used to access the data warehouse relational database. Multidimensional 
30 analysis systems have been available for over 1 5 years; first on mainframes and then on 

client/servers. Under multidimensional analysis, data is divided into the dimensions and facts 
needed to manage the business. Dimensions for marketing applications may include 



PCT/US99/09633 

. WO 99/57658 * 

products, markets, distribution channels and time periods. The dimensions are used to 
reference specific points in a database. What that point represents is called a fact. As 
examples, units sold, revenue, and price are all facts. Dimensions are further described by 
attributes, such as size; flavor, location or fiscal year. Attributes also describe hierarchies 
within a dimension, even overlapping and inconsistent hierarchies. These hierarchies 
determine the vertical relationships within a dimension. For example, in a Period dimension, 
a standard hierarchy is year -> quarter -> month -> week -> day. By defining these 
hierarchies, it becomes possible for OLAP applications to automatically shift their 'view' up 
or down a hierarchy. This is commonly referred to as 'drilling' within this application space, 
an example of this would be shifting an annual report's total. 1997 data down to view the 

individual quarter's numbers. 

Multidimensional analysis allows users to select, summarize, calculate, format and 
report by dimensions and by attributes within dimensions. It can be used to^support virtually 
any time-series decision support application including reporting, analysis, forecasting and 
budgeting. 1 • • • «*- r ,,v • < .~r, ;-:;>'.: vr •• =* • - ; 

To be useful, decision support systems must support analysis based not only on < , 
historical data but also on projections for mture activities. ^ 

project sales for the next three months. ^ These figures may men be mtroduced mto a model 
used to tune manufacturing output over that period of time. To date, such analysis has been 
performed using multi-dimensional databases having fixed locations, What is needed is a 
system and method of extracting and modifyirigJnfonnation from an existing database which 
can be applied to a relational database in order to:free the organization from the space 
lirnitatidhs of multidimensional databases: In addition„what is needed is a system and 
method capable of creating reports not only based on existing information but also on 
projectiohs-of future activities." ..••;'..••:--'•'-*; 

,. f!: ; ; : ; Summary thet Invention . ;. 

The present invention is a data warehouse system and method, -The data warehouse 
includes a memory and a processor. The memory includes a database having a plurality of 
data entries. The processor includes a cache and an override engine, wherein the cache 
includes a subset bfthe plurality of data entries and wherein the override engine extracts data 
from me cache for viewing by a user, modifies the data in response to one or more user 
commands and saves the user commands to a file for later application to the database. 
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According to another aspect of the present invention, a data warehouse is described. 
The data warehouse includes a plurality of workstations connected to a memory , by a server. ; 
The memory includes a database having a plurality of data entries. The server includes a , 
cache and an override engine, wherein the server operates in response to user commands to 
5 store a subset of the plurality of data entries in the cache, wherein the override engine extracts 
data from the cache and sends the data extracted from the cache to the client workstation for,, 
viewing by a user, modifies the data in response to one or more of the user commands, saves 
the user commands id a file and operates in response to a commit command to modifies the 
database based on the user commands stored in the file.': ■■. o - . . . . ■ ' • ". ' 

10 ' According to yet another aspect of the present invention, a method of reporting data , 

from a data warehouse is described in which the steps are providing a server and a memory, 
device, storing a database in the memory device, wherein the database includes a plurality of 
data entries, extracting a subset of data entries from the database; storing the; subset of data 
entries on the sewer, modifying me data-entries stored ori the server in response to user . 
1 5 commands, reading data from the modified data entries stored on the server and displaying , . 
wedatato weuser. ^i--^ !<^wm : :.:-\q}>\.>. r»o. '- : 

According to yet r another aspect bf the present irivention, L a method of forecasting 
based oh data in 5 a data warehouse is.described in which the steps are providing a server and a 
memory device, storing a database in thememory device* wherein the database includes aji-. 
20 plurality of data entries, extracting a subset of data entries from the database, storing^the r 

subset of data entries oh me server, modifying^;data:entries,stbred on me server in?response 
to user commands, storing the user commands, reading data from the modified data, entries - 
stored on the server, displaying the data to the user and ; modifying the database based on the 
stored user commands. - *•■■::<•■ ..-:/.>.:, ••-.> )■ -a -j </!•.-»■,. i . ; -.Ur ';••••> >\.\-' 

25 According to yet another aspect of the present invention;, a method of increasing the 

speed in which changes to a relational database are reflected back to the user is described in 
which the steps are extracting a subset of: data from the database, wherein the step of 
extracting includes the steps of displaying a representation of the subset of data tp ; the user 
and storing the subset of data in a cache, receiving a data modification . command, storing the 
30 data modification command in a file and applying the data .momfication cpnmiand against the 
subset of data stored in the cache, wherein the step of applying the data jnodification 
command includes the step of modifying the subset of data to reflect application of . the data 
modification command. ; - " ' ■ ■ ■ ' 
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Rri»f r>ftRrr iptif>P " f T>rawingS 

In the drawings, where likenumerals refer to like components throughout the several 

Figure 1 shows a data warehouse decision support system ^ according to the present 

invention; 1 ; ^ 

Figure- 2 shows amore detailed implementation of the data warehouse decision 

support system of Figure 1; 

Figure 3 illustrates a star schema implementation of a data warehouse according to the 

present invention; * : • *• \ c . ^ ^ ; j 

: Figure 4 is a more detailed description of a data warehouse according to the present 

invention; 1 

: Figure 5 shows an alternate embodiment of data warehouse and decision support 

system according to the present invention; and * 

> Figures 6a and 6b illustrate distribution of adjusted data across levels in an unlocked 
> and a locked systeni, respectively. >:^: : . s : yz^r:o- ; ;..-y:.rr::-:\ i wr:- 

In the following detailed description, of the preferred embodiments, reference is made 
to the accompanying drawings which form a part hereof.and in which is shown by way of 
illustration specific embodiments in which the invention may be practiced. It is to be ; ; 
20 understood that other embodiments may be utili^ and stmctural changes may be made 
without departing from the scope of the present invention. . , 

Figure 1 illustrates a computer system lO haying an enhanced capacity to ; extract and 
modify data stored in a database. Computer system 10 includes a memory 12 connected to a 
processor 14t Processor 14 includes alcache 16, a reporting tool 19 and an override engine 
25 18. Memory 12 is used to store a database 20. database 20 includes aplurality of data 

entries26. . ; i •• -. • ■ •- • " y-, - : - - AS ' r ' 

Mone embodiment, prt>cessor 14 also indudes an mstruction. application proc^^ 

for permanently applying the modifications made within override engine 18 to data entries 26 

stored ^database 20. In one such: embodiment, database 20 is a data warehouse and override 

30 engine 18 is implemented as a multidimensional data entry/edit software engine process 

which supports the creation and adjustment of data points in the data warehouse. 
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In one embodiment, as is shown in Figure 2, cache 16 is implemented as a persistent 
cache which stores a subset of the plurality of data entries 26. In one such embodiment, 
override engine 1 8 extracts data from the persistent cache for viewing by a user, modifies the 
data in response to one or more user commands and saves the user commands to an : ; , 

5 instruction file 30 for later application to database 20. , , 

A user sends commands to processor 14 over command interface 22 and receives r 
reports based on data extracted from database 20 through report interface 24, In one o, 
embodiment, as is shown in Figure 2, command interface 22 and report interface 24 are 
implemented as a single graphical user interface (GUI) 32. ; . i 

10 User action within system 1 0 is basically an adjustment process of data representing 

future periods in time. In one embodiment, this data will have been pregenerated by- other 
systems and stored in the database 20. An example of this would be a statistically created 
forecast of future volume. A user can then "override" or adjust the values (i.e., facts) that > 
they consider to be inaccurate. The combination^ of the adjustment capability with the OLAIV 

1 5 ability 'to present the data ih virtually any level of granularity allows business professionals to 
review data within a familiar business context and use their knowledge of the, business to ; . 
refine the data warehouse values. 

As with a standard read only OLAP repotting system, System 1 0 allows end users and 
administrators to define reports to brgatiize? arid present data. These reports are created by *# 

20 selecting the desired dimensional' identifiers as well as the facts that contain the data needed 
to support the decision 6r planning process. As ah example, a report may contain facts ^uch • ; 
as 'Annual Plan/ - Statistic 'Central - 

Region,' 'Corn Syrup,' and 'May 98yJune 98> and July 98.' ' .r-_ 

1 : " All the data the user sees oh the report is ^stored in a work file that was creat?dtfor that 

25 Adjustment cycte. The process administrator creates one worfc file for each adjustment cycle. 
For example, in a monthly planning cycle there would beg one work file for the May 4996 ; 
cycle, bne for the June 1996 cycle', and scJ On- ^ ^ •. - * ; > \y. •■> • > - 

When the user adjusts a fact value, the information is saved in a report file, not the 
work file. In the embodiment, when' the final adjustment^ the fact is completed, the process 

30 administrator updates the database with the new forecast data.- ; = \ ; o 

As an example, the following chart summarizes a typipal adjustmentcycle; In; this > 
case, a cycle used to create a consensus tactical forecast is shown. The cjiart identifies^the 
required input, the steps^ and the results. / v . - ' :, 
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Override Process: Tactical Forecast Cycle 


Input to the Cycle 


Steps of the Cycle 


Results of the Cycle 


Statistical forecast data, 


1 . Users create reports using 


Preliminary reports. 


tactical work file, 


filters and dimensions.. 




i 

tactical fact. 


They work only with the 






assigned products/ 




• 


markets/periods. 






2. Users adjust last month's 


Tactical forecast 


i 

i . * 


i tactical fact to create this 


reports for others to 




month's tactical forecast. - 


review, work with, and 


i 
t 


They save the forecast 


change. 


■ 


amounts, and distribute 






the forecasts for review. 






3. Users make final changes 


Final version of tactical 




and save the tactical < . 


forecasts. 




forecasts. r , • ;•>•.•■.?:- 




Report files, tactical 


4. Forecasting administrator; 


Management work file, 


work file. * f . 


completesthe cycle. ; ; 


management fact. 
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As an additional Example in which the override, function is used in a forecasting 
application, the following chart summarizes a subjective management forecasting cycle. It 
10 identified the required input, me steps, and me resiilts: . 
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Override Process: Manageinent Forecast Cycle 


Input to the Cycle 


Steps of the Cycle 


Results of the Cycle : 


Management work file, 


1 . Users create reports using 


Preliminary reports. ; 


management fact. 


filters and dimensions. 






They work only with the 






assigned products/ 






markets/periods. '•< ■'- 




' " * 


2. Users adjust last month's 


Reports for others to 




management fact to * 


review, work with, and 




create this month's 


change. 




management- forecast. ■ • ; j 






They save forecast ' 






amounts, and distribute - 






the forecast for review. 






3. Users make final changes 


Final version of 




and save the management 


i management forecasts. 




forecast 1 r ' H(r * >a: ' - 7t ■ 




Report files, . l r ^. 


4: Fprecasting adnnnistrator ; y-.y 


Final business fact. 


management work file. 


completes the cycle. 





At the end of each cydle; the process adnrinistratbr prepares the data for the next 
cycle. This involves saving the dataHo tlie database, preparing the work file,for the next ♦ 
cycle, and setting up the single adjustable fact for 'that cycle. The adjustable fact is the fact ; 
10 that can be changed or overridden. 

For example, at the end of the tactical forecast cycle, the Forecasting administrator 
updates the database with the consensus tactical forecast and sets up the next planning cycle, 
in this case a consensus management forecast. The following chart lists the steps. 
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Input to the Cycle 


Steps taken by the Forecasting 
administrator 


Results of the Cycle 


Work file for the cycle 
(tactical work file, and 
management work file) 


1; Appends all report files 
from all users. 

2. Commits the data to the 
Forecasting database. 

3. Sets the fact to be 

, adjusted in the next 
forecasting cycle. 


Integration of forecast 
rules. 

UpUalvU -T Ul CWao ling 

database. 

A new adjustable fact 
for the next cycle. 



5 A forecast override application such as system 10 allows users to apply qualitative 

methods (i.e., business knowledge) to the forecasting process. Users can change values 
generated by purely statistical methods to reflect changing business conditions. 

In one embodiment, system 10 maintains a master activity ffle. The master activity 
file consists of the full set of dimension mformation user information, and security 

10 information It also contains detailed information about all of the facts mat were chosen by 
the process administrator \o support the planning or adjustment process. It is stored in only 

one place. .. .., . . , . )iilv -,- >r ;-, ,-,.■>>>•■,*,■. . „ • ;;>,/■, ,• , 

Individual users have meir own cor^guration files ^ appropriate fact data files. 
When the override application is started, the master data file is read and the entire dimension 
15 class is built m memory ^ 

master structure points to. A system end user can view and modify any data that he has 
permission to see. The data that they are allowed to see can ^e configured on a user by user 
basis to^e^ure mat they see ^ 

A lpck file is created while the work file is bemg s processed by a user to ensure atomic 

20 usage ofthe data in the file...-.; , ,r t>v.' ^ 

Reports . ; . ... ... ...... .>> •• • , : >h >: . 

In one embodiment, reports are created, from a template. The template is like a 
blueprint for the report. Each time a report is created, system 10 saves tiie blueprint. 

Inoneemb^ 

25 create their own version ofthe report. For example, they can run a new. report, modify the 
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report template, or "drill" to creatie a different version of the report, By drilling, they are able . 
to review and adjust the data anew, with more discreet levels of detail. As an example, 
instead of simply adjusting the fact 'Planned Budget* up by 25% at the annual level, the end 
user may 'drill down' to the monthly level and reviewand adjust specific months values. ; , \ 

All reports contain one or. more columns and one or more rows. Each report can 
consist of multiple sections. If a report contains multiple sections, each section contains the 
same type of row and column information. 1 

The section, column, arid row names in a report reflect the dimensions of database 20. 
These dimensions give meaning to the values in database 20. It is, therefore, important to 
understand how the dimensions work together. 

Every data value in database 20 is defined by one or more dimensions. To fully 
describe each value, a report must contain at least one element from each of the available 
dimensions. 

Period dimensions are time intervals used for identifying and consolidating the data, ! 
such as weekly, monthly, quarterly, and yearly intervals. Non-period dimensions describe £ 
other aspects of your data. Non-period dimensions ma include, for example, Geo-Poliiical, 
Product, and Business _Org. 

Each dimension can consist of hierarcluc^ levels, For example, prdduci may be a \r 
dimension. Brand and SKU are associated product dimension levels. The levels represent 
differing degrees of detail and the paths useid when you drill. ' " * 

In one embodiment, database 26 is a data warehouse siored in one or more work files. 
Each work file can contain an unlimited number of data points. (That is, the wbrk file size is 
limited only by the amount of physical storage.) lii one sudh embodiment database 20 is 1 
represented as a multidimensional database, bvemde engine 18 can nfddify and view data 
points at any combination of levels within the multidimehsiorial database and, as Values are 
changed, the new values are allocated to all levels of the dimension hierarchies. 'This ensures 
that summary levels of the data still total correctly. User instructions to tife override engine 
18 are not applied to the data points. Instead the instructions are stored in instruction file 30. 
Since a single instruction may change tens of thousands of rows, just storing the instructions 
is much faster and less expensive than storing all the changed values; ' Once editing is 
complete the edits can be applied to the work file by executing instructioh application process 
34. In this way, large scale data warehouse updates can be perforriied offline while the user is 
working on other tasks. 
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. By storing the instructions rather than, automatically applying them* computer system 
10 can present the user with the results of the desired changes .more quickly than in previous 
data warehouse analysis products. In addition, by using one or more work files rather than a 
predefined multidimensional database (MDDB) product, system 10 can handle data 
5 warehouses which are larger in size than current database products. 

In one embodiment, override engine 18 extracts the subset of data entries 26 from 
database 20 and stores the extracted data into cache 16. In one such embodiment, override 
engine 18 employs the same mechanism used by reporting tool 19 to extract data from 
database 20. For instance, in one such embodiment, both override engine 18 and reporting 
10 tool 1 9 determine the appropriate levels of data to extract from database 20 by querying an 
OLAP object ixmning on a standard request broker. Similarly, both override engine 18 and 
reporting tool 19 look to a Metadata table such as Metadata table 36 to identify fact tables, 
determine the levels they need in each fact table, and to extract the data from each required 
fact table. Override engine 1 8 then takes the report generated and pushes it into cache 16. 
1 5 From that point -on, override engine 1 8 receives a command, executes the command, and 
presents the data to the user, i In. addition, override engine 18 stores i; the command in , 
instruction file 30 so that if one wants to rerun mat report later,, all that has to happen is that 
the commands are reapplied to ;the known : ,startiBgppinL ;; ,;;^H_ j;;- ?V : . 
• As noted above, 'override engine 18 provides the user, or users with a mechanism for 
20 quickly adjusting data stored in the data warehouse during a subjective fact adjustment , 
session. ' In one embodiment* data stored in me data warehouse can be in any of three states 
durmg such an adjustment cycle. Data ■■that. came put of ^<iatabase.20 is "untouched.", ; , 
Commands to alter the data are stored to instruction file 34 and are used to change, the data 
being displayed to the user. The commands do not, however, change the data in either cache 
25 16 or database 20, , . % ■ ;L ^ _. r -; v. <••• 

' Data that's been stored back to the data warehouse (i.e., stored in database 20) is 
"adjusted" or "written" data. Data in database 20 is modified using the instructions stored in 
instruction file 34 via a "commit" command. In one such embodiment, data stored in 

persistent cache 16 is invalidated during execution of the "commit" command 

30 Data which hasvbeeh adjusted in cache 1 6 but whichhas not yet been written to 

database 20 is in that more nebulous state in the middle where it is adjusted but not 
committed. And that's the situation where cache 16 does not match what's in the data 
warehouse anymore. In one such embodiment, the data gets to that state by executing a 
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'^release" command in engine 18. The "release" command causes override engine 18 to apply 
the commands not only to the data presented to the screen but also to the data within cache 16 
itself. In one such embodiment, commands must be Pleased" before the resulting changes 
are "committed" to database 20. Once a set of commands are "released", however, the i i 

5 original data is gone. ' ; .. . 

In another embodiment, override engine 1 8 maintains a stack of old states and the user 
can scroll back through a list of releases to recover an older state of cache 16. - 

In one embodiment, system 10 only extracts data from database 20 at the. start of ; the 
forecasting process. In such an embodiment, systeih 10 only extracts data from database 20 

10 at the start of the forecasting process: In siifch an Embodiment, System 10 applies a three-step - 
process: work file generation, interactive overriding,* and database storage. Work file > 
generation is accomplished using the extract phase. Extract reads the base statistical forecast 
data from database 20 and stores the data in a Work File (cache 16) in the UNDCfile system ^ 
of processor 14. J ■ }i " ' : : '- *- - : ' 5 - : •'• • " :L - 1 - ' 

15 The remaining ph&fcs (override, release* aiid commit) use the data in the Work file to 

generate adjusted fact dalta: System 10 allows the user to interactively change individual ? 
product or rriaikfet Values to reflect changing feiKsiiless conditions. Each adjustment is : ; •-re- 
allocated up and down the dimension Wferarchy Aggregation levels): ^ Allocations are . ^ 
performed by iisihg the dimension's drill hifertrChy toMdentify lower level components of the 

20 data point adjusted. Thfese lower level cbmpioherrts are then^given the new value that v 
maintains their relative contribution to adjiiSted Valub: Users may :also lock or unlock , - A 
individual vkliie^ so that the values do not change during the adjustment process (directly or\ 
indirectly). ' • ' ' ; ' iV> y r > ' 1 ■■ - — ' > ' : - — * ■ ;7;;uc... ; 

Once the adjuster has completed all work for an override, the adjustment is checked- 

25 in to the work file. The check-in process ensures that two adjusters do not adjustthe same 
values and, in one embodiment, it allows a process administrator to review the work before 
commit. ■ 1 ' • r.^vjf- ."*cr: -M ' ; - : , . ■ • v-;o u---/ 

The final phase of the override process is the database storage phase, or commit. 
Once the user or administrator is satisfied with the generated overrides, the overrides must be 

30 committed to the database^ This is accomplished in the storage phase, v >' : -? 

As noted above, extraction is the first phase of the override process, It is the : 
generation of the work file. Extraction builds a snapshot of database 20 and stores the ;s 
snapshot in the Work File in the UNIX file system of processor 14. Extraction is generally 
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done once because it is a time-consuming process and you generally do not want or need a 
user to see that happen. In one embodiment, the extraction process is performed by an agent 
executing within reporting tool 19. The agent will typically be set up to perform the 
extraction process after database 20 is refreshed. 
5 In one embodiment, the extraction agent operates in response to user commands to 

extract the correct level of data from database 20. In one such embodiment, one could set up 
system 10 to respond to a command such as "I want these markets by these products for this 
period on the horizon, by channel" (or whatever your other dimensions are). Another 
command syntax.might be "Give me all my products and give me all my markets at the 
10 region level over a selected forecast horizon" (e.g., current to current-plus- 12). 

In one such embodiment, refresh of the persistent cache is triggered by the current flag 
moving forward.one month. For example, if the current month switches from January to 
February, a subset of data is read from database 20 and a combination of facte from database 
20 and calculated facts formed as a function of data in database 20 are stored in cache 16. 
1 5 Any data resident in persistent cache 1 6 at the time, qfthe refresh that is unsaved or 

uncommitted is simply overwritten. (..•: v -. -.v. t - jS ^ ■ ^ - ; ; < 

To build the .Workjile; the system IQ muj^d t etexm^ jirhic^h dimensions arc drillable 
and at which aggregation levels the npn-drillable dimensions will be forecast. In one 
embodiment, this mformatiort is stored m-the Categoryj > i. .- .. . • 

20 For drillable. dimensions, data is stored in the Work File at the lowest level defined in 

the drill hierarchy for that dimension,, FpipnQn-driUable dMensiorisj' data is stored only at the 
level of aggregationrspecified in.the Metadata for that : dimension. , . , .. , .... 

Or; The Override phase allows the user to jnte^tiyely.adjust .the base statistical forecast 
data. Data is read from the Work File generated by- the extraction phase. The user is allowed 
25 to adjust values, lock and unlock values, drill up and dpwn.the, tollable dimension's 
hieraidiy,'as'weU-asi^yomerfun(^ons. c . , }C . ->j- ;. •• r . . ; , 

Once an adjuster, has completed a set of pyerride changes, these changes are released 
to the work file so that they are available for final cornmit to the warehouse. The release 
phase loads the base data from,the work file, loads an .instance flip which contains the saved 
30 set of changes, and.writes the new values ^^back to the work file. .. , .. 

The commit phase performs the commit for the Override process. First, it reads the 
Work File. Next, the data values of the lowest-level decomposed data are read from the 
warehouse. These values are used to properly proportion the data as it is decomposed to the 
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lowest level in each dimension's hierarchy. Finally, the adjusted and decomposed data is ■> 
written to the database. , . 

For example, suppose the data in the* Work File is stored at the regional (REG) level ••• 
of the Market dimension. Further suppose that the lowest level in the Market-hierarchy is - 
market (MKT). Store will read the REG level data from the work file, decompose the REG 
level data to the MKT level, and finally write the MKT level data to the database. 

The DatahW Stnictnre 

In one embodiment, database 20 is impleriierited^ a non-normalized star schema, v A 
simplified version of a star schema 38 is shown generally in Fig: 3. In astar schema, facts are 
stored as data in fact tables. The fact tabids are indexed by a multi-part key made up of the 
individual keys of each dimension: Similarly, dimension information is stored in dimension 
tables. In the embodiment shown in Fig.' 4; DimTable 40 is a dimension table while the A 
tables labeled '^Warehouse Product", "Warehouse' Market", "Warehouse Period" and •*.» 
"Warehouse Fact" are fact v ^les 4i, 44 ; i: : ■"■ ■ • 

Non-normalized star schemas are designed for very fast data aggregation and -v 
calculation! Such speed can be vety ^ the subset of data to be stored 

in cache 16.' Such 'sysl^ms can;lioSve^fbog down eonsiderably when required to perform?; 
incremental updates (e.g; 1 , as' is the case 1 during' a for ecasfihg session); That is where the use* 
of cache 16^^ such forecasting sessions. 

the'downsideof a^ ? ' v ' ; 

replication of data across tables! ' 'At the "sanie Hme, nbweverl this replication of datagive you 
the ability to get your keys frbm me daia Wafehbus^e wim very small queries that database 20 
certainly can handle qWcklyl 'Sb a star schema: approach is veiy well optimized for queries: 
that pull a large number of rows out of database ,J 20. ' ' ' r > ■■ > ; 

Standard OLAP reporting tools do not have to understand multiple levels within a 
product or market hierarchy of a multi-tiered datawarehbuse: ; This is a key difference 
between override engine 18 and a standard OtiAp reporting tool: Override engine 18 must 
understand multiple levels at 'the same'tinie because for the purposes of an adjustment, there 
may be interdependences on the levels themselves for a reporting tool that essentially say, 
"6.¥L, here's data at this level," or "Here's data' at the cbmbination of these two levels." 
They're largely independent of each other arid you can concentrate ori one or the other at any 
given time. Because of that, override engine 1 8 does not run directly against the warehouse. 
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Instead, override engine extracts that data, performs calculations where necessary and stores 
the modified data to cache 16. * . ; ■ . > . .... 

In order to operate correctly, however, with database 20, override engine 1 8 and 
instruction application process 34 mufet understand the structure of database 20. In one 
embodiment, as is shown in Figure 3, override engine 18 and instructipn application process 
34 extract the structure of database 20 by reviewing the contents of Metadata table 36. 

Such an approach permits the use of an unlimited and easily alterable number of 
dimensions; In its simplest form, metadata table 36 includes a period dimension table 40 and 
a fact table 46. In one embodiment, each dimension table includes a unique key, unique 
description field, a level column and a hierarchy level column. In addition, period dimension 
table includes a unique sequence number column* a sequence within year column and a 
current period column. Fact table 46 includes keys which are identical in type and structure 
to the keys listed in dimension table 40. 

For example, the metadata table can be used to drive a drill hierarchy that tells 
database 20 that days make up weeks and weeks make up months and months make up 
quarters* quarters make up halves, halves make up years.; Or, that four quarters make up a > . 
year, so that the user can jump and skipttiings.. Same thing in the product hierarchy.^ j 
Override engine 1 8 and reporting engine 19 understand the Metadata structure and use the 
data stored in the dimension tables to extract data from database 20s; ^ r : v r ^ 

4 - For Sxampte, a certain table may include a category of sales by total U.S. And maybe 
it is category, manufacturer, brand. And then over in another table are lists of SKXJs by store. 

Another approach is to have a separatevfact table for each month's data. That way 
when the next month's data arrive, it gets placed into a new fact table and stored in; database 
20. An advantage of such an approach is that if one of the fact tables gets lost or corrupted, 
you can reload that month. In addition, as database 20 gets bigger arid bigger, its value to the 
compafiy increases arid so does the tost of maintaining the database. Relational databases can 
scale into much larger data sizes and aire much more maintainable than a corresponding multi- 
dimensional database. ; s -r<- < j . 

It should l>e understood that database 20 may be distributed across a number of 
computers. In one embodiment, such as is shown in Fig. 5, computer system 50 includes a 
server 52 connected to a processor 58 arid a processor 62 by a network 56. In addition, server 
52 is connected to apluraiity 1 through N of workstations 62. Processor 5 8 and processor 62 
store portions of database 20 in memories 60 and 64, respectively. 
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In one embodiment, as is shown in Fig. 5, server 52 maintains a sepai^e instantiation 
54 of override engine 1 8, reporting tool 1 9 and cache 1 6 for each user performing the • : 
forecasting function. In another embodiment (not shown), a single cache 16 is used across all 
users. In either case, changes to cache 16 are maintained in a separate instruction file 30 for : . 

5 each instantiation 52 and are only applied to the cache on receipt of a "release** command. . 

In one embodiment, processor 58 is a multiple processor machine such as the Hewlett 
Packard HP9000 running an Oracle database application while processor 62 is a Tandem 
Himalaya 128. In one such embodiment, aggregated data is stored in the Oracle database on/, 
the HP machine while the lowest level data is stored in the Himalaya machine. The Metadata : 

10 tells the program the appropriate processor to which a query ' should be addressed. For . 3 
example, if data is stored by category by store in processor 62, override engine, 18 can - 
determine this be looking at the Metadata. If, on the other hand, the user is storing aggregate 
data in cache 16, it will determine from the Metadata table that it should extract such data ^ 
from the Oracle database on processor 58. :> v. - ; i : 

15 In another embodiment, override engine 1 8 and reporting tool 19 run as a relatively^ 

thin wihdows^clierit that essentially just provides GUI 32. All the analytics, all the storage, v ?: 
and all the^i^al processing's : I » . : • r. v> > . > ".; ; ■<■■ ; ir-- 

^ crK !: :r,> I :r v" . !: v,/; \. • \ w /• 

T ncking Values in the Database l- **ix ry^xz. ,>j 'i vc". -{-Y^ r [' ■ ?. *.*/o 
^ ^ In one embodiment, override engine; includes the ability, to lock values in database 20. 

20 As noted above; on a release; the changes at one level of the hierarchy are pushed dpwn to, $; 
each of the sublevels of the hierarchy.: For example, if production is increased across the 
board by 10,000 units, the 10,000 units are distributed proportionally across each of the : ;!v; 
entities at the lowest level of the hierarchy. ; : ■ •*-. ■ ;i: -■- 

hi certain situations, such an approach does not make sense, \ffor instance, if one pf 

25 three manufacturing plants is operating at capacity; it .makes, little sense to distribute the , . - 

increase proportionally to the plant operating at capacity. For such* situations, Qyerride engine 
1 8 includes a locking mechanism which can be used to lock the output of any of the , 
manufacturing plants to a certain value. Any increases are then distributed proportionally 
across the remaining, unlocked, .manufacturing plants; v >: > r: 

30 ' ( In one embodiment; the adjustment report displays the values of the dimensions the 
user selects bri a Template dialog screen. The only values that can be adjusted for the- , 
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forecast are found in the unshaded cells. Locked values are shaded red and non-adjustable 
values are shaded yellow. 

The user can adjust a value at any level and the effects ripple through the rest of the 
product hierarchy. For example, if he or she adjusts a SKU value, the values of products at 
5 higher levels change to account for the lower level adjustment. Or, if the user adjusts a higher 
level value* the values for the lower level products change as needed. 

Likewise, when the user locks a value, product values both.up and down the hierarchy 
may be affected. For example, if the top level is locked at 100, all lower values must total 

loo. • ' ' . : •■• ; ' ■-• ■■ ■ ' ■■■ •• - ••• • • 

10 The diagram shown in Fig: 6a is an example.of decomposition or proportional fitting 

based on Current forecast dat* The current adjustment data is retrieved at manufacture level 
70 and, after an adjustment, is proportionally propagated through Brand level 72 to SKU level 

' ■•' If; however, the manufacture product value was locked at level 70. and one Brand 
15 product value was adjusted from 50 to 60, the adjustment and its, effects are shown in Fig. 6b. 
i * As noted above, in one embodiment both reporting tool 19 and override engine 18 
have the ability tolimit the effect of commands' such-^t i tiic.dato : re^ed. l fe*^.datob^e 20 
does not include the entire hierarchy for all dimensions. For instance, one may care about 
multiple levels of product ^dimension* but would like to limit the market adjustments to a 
20 particular level (e.g i make the market adjustments at ? a total U.S. ). . In one. such embodiment, 
the user can select the level atwhich dataiis adjusted:. For example, one would tell override 
eiigme'18 to, "Make your product dimension drillable^make your market dimension non- 
driUablei niake your period dimension non-drillable^: Adjustments then must only be driven 
down the product hierarchy for display; the override engine doestnot, have to try to drive it 
25 down the other hierarchies. As you add multiple drillable dimensions, the amount of work 
that has to happen when you make adjustments expands exponentially. Not only does it go 
down product, but it has to go down product for every market, or every submarket, or every 
submarket of every submarket and you end up with a huge matrix of numbers to keep track 
Of. ' - ' ■ • ': ■■■■■ ■ - - '• 

30 Drilling allows the user to display me fact values at different product levels, bom 

arid down the product hierarchy. With drilling, one can see the aggregate values of a group of 
products, or can identify the specific values that went into the aggregate amount. 
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Drilling up works with any product where there are other products at a higher level. 
For example, one can drill up on a value if he or she is at SKU level 74 shown in Fig. 6a. 

Finally, a user can drill down with any product if he or she is at a level above the 
lowest level, SKU. For example, one can drill down if at manufacture level 70 in Fig. 6a, y; : 

5 If, for instance, you want to adjust the amount of a particular soft drink sold in a < 

particular city, you could either make that a drillable thing or a non-drillable dimension^ You ; 
can do it in one of two ways. One is you can set your market dimension as drillable, and then 
poll the whole market hierarchy in order to drill down to the city aind make the change. If, 
however, you did not need that flexibility in drilling and the associated performance impact * 

1 0 of allocating the changes through that dimension, you could make the market dimension 

'non-drillable* and only see data at the city level. Then you can just grab whatever city you 
wanted and make your adjustments. But because you probably have the data stored at some 
level below city, once you do a "commit" it is going to drive the numbers to the bottom of all 
the hierarchies. (In one embodiment, override engine drives the numbers down to the bottom 

1 5 of all the hierarchies by modifying eath number as a percent of contribution to the total.), r ^ ^ 
F6r fexaniple, if giveii a market hie^ cities within those regions 

and stores Within those cities, ydii were going to modify units at the regional level, you only, 
neecita maintain data in cache 16 ^that level vr To do this, override engine 18 initiatesa 
transfer of data at the atbinic level, receives the data and pushes it up to the regional level. ^ 

20 The aggregated regional data is T theh stored ihrcache 16 and commands from the user are t j ... 
ap^Ued ^gain^t that aggregate data. Then; when you are ready to store the changed data, a i f 
"commit" command is executed arid the modifications get drilled down to the atomic level in 
database^ 20. The result is that useTcommands get executed quickly at the regional level and 
get Stored accurately at the atomic^ level. ^ ; r >r ; _ ? <-•<:•' : ; ■ A 

25 : ' < For example^ one might determine what would happenif vqliune increased by 10% in 
a region such as the Great Lakes territory, f The change; would be made at the territory level 
and, when ; committed, it is distributed to the cities as, a function, of the percentage they ; 
contribute to the regional total;* : • o / * r.- - p f : ( . ;■ v , r 

No matter the level where the adjustment is made, once the warehouse is updated, it is 

30 updated at the lowest atomic leveland then in this case for reporting engine 19, then it can 

automatically pick up a report of it based on maricet hierarchy, period hierarchy, etc. All that 
is a trade-off between speed and flexibility. You can go ultimately flexible if you've got 
enough iron behind the thing to drive it. And if you do not, then you can cut back. 
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Also from a security perspective, quite often if it is sales people that are using it for 
the adjustments, they do not want them to see other territories, for instance, other people's 
clients, other sales guys' clients. Otherwise they start playing games that you do not want 
them playing. It is a combination of those things. , 

Override engine 18 understands all of reporting tool 19's filters and calculated facts; 
it also understands the hierarchies of system 10. Essentially everything in the Metadata that 
can be defined, is read by reporting tool 1 9 and override engine 1 8 and they will use those 
definition. So you can create a calculated fact in reporting tool 19 and override engine 18 
will automatically see it and know how to iise it 

(An example of a calculated fact would be< gross revenue. Gross revenue is calculated 
as units times price. You would riot, therefore store gross revenue. Instead, you calculate it 
off of the two that you did store (price and units). Another calculated fact is forecast error. 
Facts calculated as a function of an actual fact and a forecasted fact are derived, not stored. 
Override engine 1 8 automatically reads the definition of each calculated fact out of the 
Metadata and applies them on the fly to the data read from database 20.) ; ; 

e In one embodiment, forecasts ^e stored as separate dala^ For 
instance, one could include a dimension labeled "scenario" into the warehouse. It pan, - 
therefore; be critical to have the ability to add extra dimensions to systems 10 and 50. 

Cache ' : '-'"- J - v ; - "° ' : "' s <■ ; 1 K '"' ; ' v ^ ' • V ; <• v 

As was noted in connection with Figure 2, in one embodiment cache 16 is a persistent 
cache stored as a B-tree in a UNIX file system on processor 14. The B-tree allows you to 
essentially go with a much more compact data storage in situations where the matrix of data 
is populated sparsely (such as in, for example, customer centric databases) yet, at the same 
time, a B-tree implementation does allow you to get reasonably fast access times. 

In one such embodiment, the persistent cache is implemented using standard Rogue 
Wave B-tree code. The performance of the Rogue Wave B-tree code can be enhanced by 
replacing the standard I/O stream (which is write character by character) with an I/O stream 
which writes data in large blocks of data. 

In addition, with a B-tree implementation, one can trade off size for speed by 
increasing or decreasing the number of branches and subbranches in the tree. That is, the 
deeper you make the B-tree, the slower your access time but, at the same time, the smaller the 
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actual physical storage; In one embodiment, the structure of the B-tree is optimized for size 
over speed. * ' ' .. 

In more densely packed matrices of data, cache 1 6 can be, implemented as a set of file- 
based arrays. Such arrays are very fast, requiring only simple calculations to get to the right t ; 

5 locations. They can be, however, very inefficient space-wise. Typically, if one of the 

dimensions of the data warehouse is customer, and the number of potential customers is large, 
you are better off selecting a B-tree implementation for cache 16. , , f : 

Override engine 1 8 allows the user to grab slices of data from a database that may be / 
too big to comprehend in its entirety. Override engine 18 allows you to, slice a portion of the , 

10 database out, which sometimes in the industry they f 11 refer to as a datamark, automatically 
and intelligently through the user of metadata. The iportion extracted can be dealt with either 
within or outside the database quickly and efficiently; - Once, the changes are in place, 
override engine 1 8 automatically and seamlessly pushes them back into database>20. The 
result is a database tool which eliminates the query traffic bottleneck of traditional approaches 

15 to relational database management systems. ( ; uo <; f ; • ; 

0 Although specific; embodiments have been; illustrated and described herein, it will be 
appreciated by those of ordinary skill in the art that any arrangement which is calculated to 4: y. 
achieve the same purpose may be substituted for the: specific embodiment shown. ITiis ; ^ 
appUcation is intended to cover any adaptations or variations of the present invention. 

20 Therefore, it is intended that this invention be limited only by the claims and the equivalents , 
thereof.-'-'* - : .•".•'■-'•*■ ■ ? >* ;h - - .[ X yu^)'-j -j-;- .-»« xnri\ r. : v. /• ' 
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What is claimed is: 

1 . A data warehouse, comprising: 

memory, wherein the memory includes a database having a plurality of data entries; 
a processor connected to the memory, wherein the processor includes: 
■v.) a cache; and j ^ 

an override engine; 

wherein the cache includes a subset of the plurality of data entries and wherein the 
override engine extracts data from the cache for viewing by a user, modifies the data in 
response to one or more user commands and saves the user commands to a file for later 
application to the database. 

2. A data warehouse, comprising: 

memory, wherein the memory includes a database having a plurality of data entries; 

a server connected to the memory, wherein the processor includes: 
v.- :/\ a cache; -..and.. .-: t . • -^<r^ <;v ! '.;.-? p, i^iw- - : :v\;:.ri.r-- u-. 

an override engine; and - I0 , j; 0< ,,,.i- T . ., tn ., ^ : , * ^ : 

adient workstation connected to fee : seiyer; : i , r . ( - ^ ; : ; f ; :^ ;:r; 

wherein the server operates in response to user commands to store a subset of die 
plurality of data entries in the cache, wherein the oyemde engine f extracts data from the cache 
and sends the data extracted from the cache, to^the client workstation for viewing by a user, 
modifies the data in response to one or more of the user, commands, , saves the user commands 
to a file and operates in response to a commit command, to modifies the database based on the 
user commands stored in the file. xv / ^ ;v *' «.■• ■ 

3. A method of reporting data from a data warehouse, the method comprising the steps 
of: 

providing a server, and a memory device; f , Cj , ; ^ 

storing a database in the memory device, wherein the. database includes a plurality of 
data entries; : . , 

extracting a subset of data entries from the database; 
storing the subset of data entries on the server, » ». . . . , 

modifying the data entries stored on the server in response to user commands; 
reading data from the modified data entries stored on the server, and 
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displaying the data to the user. . . . / 

4. A method of forecasting; comprising the steps of: - 
providing a server and a memory device; 

storing a database in the memory device, wherein the database includes a plurality of 
data entries; 

extracting a subset of data entries from the database; - - 
storing the subset of data entries oh the server; - ' 

modifying the data entries stored on the server in response to user commands; r; 
storing the user commands; 

reading data from the modified data entries stored on the server; 
displaying the data to the user; and ^ ' 1 i ^ - 

modifying the database based oh the stored user eo 

5 . A method of increasing the speed in which changes to a relational database are; 
reflected back to the user, comprising the steps of: 1 y 

extracting a subset of data from the database; wherein the step of extracting includes 
the steps of: ! : - < ->^oci>, • .m yj <: - - ■> --r-y 

displaying a representation of ■ffie^bset"df-data'toithe..usen i and > : , ; 4 ■ ^ 
* - ; storing the subset' of data-in a cache; ^ > ^ r - * r < : i« . o 

- receiving a data modification coiimitod? ^ - - ^ r - > r ; : ^ : 
- ; storing the data modification* <bh^ and : ; tj f .t? f ' o* 

applying the data modification command against the subset of data stored in the 
cache, wherein the step of applying the data modification command includes the step of 
modifying the subset of data to reflect application of the data modification command: 

6. The method according to claim 5, wherein the step of applying the data modification 
command further includes ; the step -of modifying the representation of the subset of data to 
reflect application of the command. ^ 

7. The method according to claim 6, wherein the step of applying the command further 

includes the steps of: *' ' ' - '•*■"' : f J i ^ v : r ^ y 

waiting for a "commit" command; and .••■•■>*,•• . ; i r 
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on receipt of the "commit" command, modifying data in the database to reflect 
application of the data modification command. 

8. The method according to claim 5, wherein the step of applying the command further 
includes the steps of: 

waiting for a "commit" command; and 

on receipt of the "commif ' conmiand, ; modifying data in the database to reflect 
application of the data modification command. 

9. A data structure for updating a database, comprising: 

a plurality of user data-modification commands, wherein the plurality of user data- 
modification commands provide information for modifying information in a database (20). 

10. The data structure of claim 8, wherein: 

the plurality of user data-modification commands provide data-modification 
; ; information for application to aggregated regional data stored in a cache (1 6), and 
modification information that gets drilled down to an atomic level in the database (20). 
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